Introduce SPORES in v0.7.0 as a generalisable mode #716
Conversation
Updated to remove outdated link to local path
Updated to remove outdated reference to Gurobi, which I was using locally
|
I see that building the docs fails because I am using matplotlib, which isn't part of the default Calliope environment. I will remove the plotting part, for now. We can later re-implement it via a supported library, or just leave it out. |
Updated to remove plotting with matplotlib, which is not supported by the default Calliope environment. Plotting can be re-implemented later, if desirable
| # ### Definition of the penalty-assignment methods | ||
|
|
||
| # %% | ||
| def scoring_integer(results, backend): |
There was a problem hiding this comment.
I have no doubt that this function can be majorly shortened by someone with deeper experience of these data structures
|
@FLomb I've updated the approach to minimise the input requirements from the user. The main change is that there is now no longer a spores-specific cost class. Instead, the objective is changed in the math. Updating this objective with user-defined math would allow a user to update how the spores scores are translated to penalties in the optimisation problem. The SPORES mode stuff is currently untested although you can see that it works in the example notebook. I hope that some of the hardcoding of params in The SPORES mode stuff will also move out of |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #716 +/- ##
==========================================
+ Coverage 96.40% 96.54% +0.13%
==========================================
Files 35 35
Lines 4397 4457 +60
Branches 599 605 +6
==========================================
+ Hits 4239 4303 +64
+ Misses 68 65 -3
+ Partials 90 89 -1
|
|
@irm-codebase & @FLomb if you could check this PR that would be great! |
|
@irm-codebase I've updated the implementation slightly to get the SPORES maths showing in the docs (you can see it under "pre-defined math" in the PR build). It requires an update to our math docs to show all defined objectives by default. To differentiate between those objectives I'm now adding a suffix to the objective name to say whether or not it is activated. Question is, is this confusing for e.g. the |
There was a problem hiding this comment.
@brynpickering changes look fine, but I am not sure why the code difference is showing changes from main...
Approved, but let's be careful just in case to avoid overwriting things on main
…s parameter setting
Which changes is it showing? |
|
@brynpickering ignore, I was incorrect (just goes to show that you should do reviews while well-rested). |
Fixes #431
Summary of changes in this pull request
sporesscenario as part of the national-scale example modelsporesscenario to create a slack cost constraintsporesscenario overrides and a custom Python function for assigning penalties at each iteration.Based on internal discussions, we have come to realise that there are many ongoing SPORES developments that may be hard to always reconduct to a monolithic run mode in the core code. Instead, it may be best to implement SPORES as a method that simply allows you to run a model in
planmode once, and then N number more times with some external function being applied between each run, with the user providing that function. This way, this mode could be used not only for SPORES but also for robustness analysis and other things.This PR aims to show how SPORES can be indeed already used in v0.7.0 based on default software functionality plus a simple for-loop and a custom Python function to assign penalties for decision variables at each iteration of the loop. To move from this to the generalised mode described above, we would only need to decide how to make some bits of this code (such as the number of iterations, and the custom Python function) a default request for inputs to the user.
The new
run-iteratively-with-a-functionmode (a better name must be found, could also bespores-and-moreif the main application remains SPORES), would essentially require the following three key inputs: 1) how many iterations to run; 2) what function to apply at each iteration; and 3) what backend parameter to updated based on the function.Reviewer checklist